Skip to content

feat: add TPS workload with netperf TCP_RR and HTTP file transfer#38

Merged
mrhillsman merged 4 commits into
mainfrom
client-server-tps
May 21, 2026
Merged

feat: add TPS workload with netperf TCP_RR and HTTP file transfer#38
mrhillsman merged 4 commits into
mainfrom
client-server-tps

Conversation

@mrhillsman

Copy link
Copy Markdown
Contributor

Summary

  • Add a tps workload that measures transactions per second between server/client VM pairs using two methods:
    • netperf TCP_RR (transport-layer request/response latency)
    • HTTP file transfer (application-layer TPS via looped GET downloads of a configurable test file)
  • Add a generic Params map[string]string field to WorkloadConfig for workload-specific settings, used by TPS for file-size, iterations, and duration
  • Update docs to reflect the new workload

Design

The TPS workload deploys server/client VM pairs as a MultiVMWorkload:

Server VM runs a single script (virtwork-tps-server.sh) that:

  1. Starts netserver on port 12865 (background)
  2. Creates a test file with dd (size configurable, default 10M)
  3. Serves the file via python3 -m http.server on port 8080 (background)

Client VM runs a single script (virtwork-tps-client.sh) that:

  1. Waits for server readiness via curl probe on :8080
  2. Runs N iterations of netperf TCP_RR (default: 30 iterations, 60s each)
  3. Runs N iterations of HTTP GET download loops, reporting transfers/sec and MB/s

Key decisions:

  • Single systemd unit per role — all output in one journalctl -u virtwork-tps.service stream
  • No UDP_RR — unreliable through masquerade NAT on OpenShift (consistently 0.00 TPS)
  • Data port pinned to 12866 — avoids masquerade NAT dropping random-port connections
  • curl-based readiness check — nc isn't installed by default; curl is already a client dependency

Configuration

  workloads:
    tps:
      enabled: true
      vm-count: 2
      params:
        file-size: 10M      # default: 10M
        iterations: 2        # default: 30
        duration: 10          # default: 60

Test plan

  • go test ./internal/config/... — Params unmarshal tests pass
  • go test ./internal/workloads/... — 113 specs pass (TPS + all existing)
    • go test ./... — full suite green
    • Deploy on OpenShift cluster: virtwork run --workloads tps --dry-run
    • Deploy on OpenShift cluster: virtwork run --workloads tps and verify journalctl -u virtwork-tps.service output on both VMs

Running Workload

❯ ./virtwork run --workloads tps --config ./config.yaml --ssh-user fedora --ssh-password fedora
Namespace virtwork ensured
Service virtwork-tps-server created
Secret virtwork-tps-server-0-cloudinit created
Secret virtwork-tps-client-0-cloudinit created
VM virtwork-tps-client-0 created
VM virtwork-tps-server-0 created
Waiting for 2 VMs to become ready (timeout: 10m0s)...
VM virtwork-tps-client-0: VMI not yet created, retrying...
VM virtwork-tps-server-0: VMI not yet created, retrying...
All 2 VMs ready
==================================================
Deployment Summary
==================================================
Run ID:       72542978-703f-4a58-9394-5d0e4cec83e2
Namespace:    virtwork
VMs created:  2
Services:     1
Secrets:      2
Image:        quay.io/containerdisks/fedora:41
==================================================

Justification

We have a partner running these tests but we do not have visibility into what they are running exactly only that they are doing client/server tps with a minimum of client performing HTTP GET file from server. We emulate that interaction and add a small 64 byte TCP packet transaction.

Workloads like TPS need custom parameters (file-size, iterations,
duration) that don't apply to all workloads. This adds a generic
Params map[string]string field to WorkloadConfig, merged from YAML
config in the run command orchestration.

Signed-off-by: Melvin Hillsman <mhillsma@redhat.com>
Add a tps workload that measures transactions per second between
server/client VM pairs using two complementary methods:

- netperf TCP_RR: transport-layer request/response latency
- HTTP file transfer: application-layer TPS via looped GET downloads

Key design decisions:
- Single systemd unit per role for unified journalctl output
- Server readiness wait (curl probe on :8080) prevents wasted iterations
- Data port pinned to 12866 for masquerade NAT compatibility
- No UDP_RR (unreliable through OpenShift masquerade NAT)
- Configurable via Params: file-size, iterations, duration

Signed-off-by: Melvin Hillsman <mhillsma@redhat.com>
@exe-prow-github-app exe-prow-github-app Bot requested review from komish and mgoerens May 20, 2026 00:28
@exe-prow-github-app

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mrhillsman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@exe-prow-github-app exe-prow-github-app Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 20, 2026
Add TPS to the deploying-workloads guide VM table and
available workloads list.

Signed-off-by: Melvin Hillsman <mhillsma@redhat.com>
Signed-off-by: Melvin Hillsman <mhillsma@redhat.com>
@mrhillsman mrhillsman force-pushed the client-server-tps branch from 8279bf0 to aaeb9b6 Compare May 20, 2026 01:03
@mrhillsman mrhillsman removed request for komish and mgoerens May 21, 2026 02:49
@mrhillsman

Copy link
Copy Markdown
Contributor Author

Verified workload deploys and runs:

[root@virtwork-tps-client-0 ~]# journalctl -u virtwork-tps.service -b
May 21 03:49:09 virtwork-tps-client-0 systemd[1]: Started virtwork-tps.service - Virtwork TPS client (netperf TCP_RR + HTTP file transfer).
May 21 03:49:09 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: === Virtwork TPS Client ===
May 21 03:49:09 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Server:     virtwork-tps-server.virtwork.svc.cluster.local
May 21 03:49:09 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Iterations: 2
May 21 03:49:09 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Duration:   10s per iteration
May 21 03:49:09 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Waiting for server...
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Server is ready.
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]:   TCP_RR TPS Test
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Msg size: 64 bytes
May 21 03:49:11 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: --- TCP_RR iteration 1/2 ---
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to virtwork-tps-server.virtwork.svc.cluster.loca>
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: Local /Remote
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: Socket Size   Request  Resp.   Elapsed  Trans.
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: Send   Recv   Size     Size    Time     Rate
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: bytes  Bytes  bytes    bytes   secs.    per sec
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: 16384  131072 64       64      10.00    3356.74
May 21 03:49:21 virtwork-tps-client-0 virtwork-tps-client.sh[1206]: 16384  131072
May 21 03:49:23 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: --- TCP_RR iteration 2/2 ---
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to virtwork-tps-server.virtwork.svc.cluster.loca>
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: Local /Remote
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: Socket Size   Request  Resp.   Elapsed  Trans.
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: Send   Recv   Size     Size    Time     Rate
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: bytes  Bytes  bytes    bytes   secs.    per sec
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: 16384  131072 64       64      10.00    3569.32
May 21 03:49:33 virtwork-tps-client-0 virtwork-tps-client.sh[1216]: 16384  131072
May 21 03:49:35 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:35 virtwork-tps-client-0 virtwork-tps-client.sh[1185]:   HTTP File Transfer TPS Test
May 21 03:49:35 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:35 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: File size: 10M
May 21 03:49:35 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: --- HTTP iteration 1/2 ---
May 21 03:49:45 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Completed:  258 transfers in 10s
May 21 03:49:45 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Throughput: 25 transfers/sec, 258 MB/s
May 21 03:49:47 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: --- HTTP iteration 2/2 ---
May 21 03:49:57 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Completed:  251 transfers in 10s
May 21 03:49:57 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: Throughput: 25 transfers/sec, 251 MB/s
May 21 03:49:59 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:59 virtwork-tps-client-0 virtwork-tps-client.sh[1185]:   TPS testing complete
May 21 03:49:59 virtwork-tps-client-0 virtwork-tps-client.sh[1185]: ==========================================
May 21 03:49:59 virtwork-tps-client-0 systemd[1]: virtwork-tps.service: Deactivated successfully.
May 21 03:49:59 virtwork-tps-client-0 systemd[1]: virtwork-tps.service: Consumed 11.916s CPU time, 3.9M memory peak.

@mrhillsman mrhillsman merged commit 9ebfc29 into main May 21, 2026
3 of 4 checks passed
@mrhillsman mrhillsman deleted the client-server-tps branch May 22, 2026 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant